1. 브랜치 전략 (Branch Strategy)
1.1 주요 브랜치
- master: 프로덕션(배포)용으로 사용되는 최종 안정 브랜치. 스프린트 종료 시 release에서 병합되며 버전 태그(
v0.0.1) 부여 - release: 프론트 팀 내 QA 및 릴리즈 준비를 위한 브랜치
- develop: 기능 개발 완료 후 테스트 및 통합을 위한 브랜치
1.2 보조 브랜치
- feature/: 퍼블리싱 화면을 실제 프론트 개발로 전환하는 브랜치
예)feature/티켓번호,feature/티켓번호 - publish/: 퍼블리싱 작업을 위한 화면 설계 또는 초기 UI 구성 브랜치
- hotfix/: 프로덕션에서 발견된 긴급 버그 수정에 사용
예)hotfix/issue-32,hotfix/issue-24
1.3 브랜치 생성 및 병합 흐름
브랜치 전략
- 작업 전
develop브랜치에서 새로운feature/,publish/브랜치를 생성 - 작업 완료 후 PR 작성 및 리뷰어 지정 (nahyeongjin1 → 6-keem → hyynjju → nahyeongjin1 순)
- 리뷰 완료 후
develop브랜치로 머지 - 긴급 수정 사항은 누구나
hotfix/브랜치를 만들어 수정 후develop과master로 병합 - 프론트 테스트 완료 시
develop에서release로 병합 - 스프린트 종료 시
release를master로 병합하고, 버전을v0.0.1단위로 태깅 (개발 기간 한정)
2. 커밋 규칙 (Commit Convention)
2.1 Commit message 구조
헤더는 필수이며 범위, 본문, 바닥글은 선택사항<type>(<scope>): <subject> - 헤더
# 개행
<body> - 본문
# 개행
<footer> - 바닥글<type>은 커밋 유형을 나타내며 아래 중 하나여야 한다.
feat: 새로운 기능 추가
fix: 기능 수정
bugfix: 버그 수정
comment: 주석 추가
docs: 문서 수정(README.md 등)
style: 스타일 수정(디자인 수정, 코드 포맷팅, 세미콜론 누락 등)
refactor: 코드 리팩토링(기능 수정 없이 구조만 개선)
test: 테스트 코드 추가 또는 수정
chore: 빌드 업무, 패키지 매니저 수정 등
perf: 성능 개선2.2 Commit message 규칙
제목 Header
- 제목과 본문을 빈 행으로 구분한다.
- 제목은 50글자 이내로 제한
- 제목의 첫 글자는 대문자로 작성
- 제목 끝에 마침표 넣지 않기
- 제목은 명령문으로 사용하며 과거형을 사용하지 않는다
feat: Add user login feature본문 Body
- 선택 사항
- 본문의 각 행은 72글자 내로 제한
- 본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기
- Created new LoginScreen for user authentication
- Implemented Firebase Auth for credential management
- Added error handling for invalid credentials바닥글 footer
- 선택사항
- 이슈를 추적하기 위한 ID를 추가할 때 사용
해결- 해결한 이슈 ID
관련- 해당 커밋에 관련된 이슈 ID
참고- 참고할만한 이슈 ID
해결: #123
관련: #321
참고: #222커밋 예시
feat: Add user login feature <- 요약된 설명
- Created new LoginScreen for user authentication <- 비교적 자세한 설명
- Implemented Firebase Auth for credential management
- Added error handling for invalid credentials
해결: #123 <- 해결된 이슈3. Pull Request 규칙
3.1 리뷰어 지정 (Reviewer Assignment)
nahyeongjin1 → 6-keem → hyynjju → nahyeongjin1
- 정해진 순서에 따라 리뷰어 지정
feature/,publish/브랜치는 리뷰 완료 후develop으로 머지hotfix/는 긴급 상황에 따라 누구나 생성 및 병합 가능- 리뷰어가 제안하는 수정 사항이 있는 경우 PR 제목을
[WIP]: **형식으로 수정하고, 리뷰어는 머지 금지. 작성자는 수정 후 request review 요청 - PR을 열기 전에 항상 develop 브랜치 기준으로 rebase 후 force push (레인보우 방지)
3.2 PR 양식 및 머지 방식
- PR 제목 형식:
[JIRA TICKET] 티켓 제목 - PR 머지 시 반드시 Squash Merge 사용
- 머지 메시지 형식:
[JIRA TICKET] 티켓 제목 (#PR번호)
예시 템플릿
<h3>JIRA Task 🔖</h3>
- **Ticket**: [티켓번호](링크)
- **Branch** : feature/티켓번호
<h3>작업 내용 📌</h3>
- 이번 PR에서 **무엇**을 구현/수정했는지 요약
- 주요 변경 사항을 간단히 기술
<h3>변경 사항 🖥️</h3>
- UI 변경이 있는 경우, 스크린샷 첨부
<h3>테스트 방법 🧑🏻🔬</h3>
- 리뷰어가 확인해야 할 테스트 시나리오, 시뮬레이션 방법
- 예상되는 결과(기대값)와 실제 결과 비교
- 테스트 환경(에뮬레이터, 실제 디바이스, OS 버전 등)
<h3>참고 사항 📂</h3>
- 관련 이슈 번호: `Closes #123`
- 참고 문서, 레퍼런스 링크
- 기타 특이 사항, 향후 개선 사항